參考趨勢科技的 何謂 Kubernetes 容器防護? 其中提到安全的一環包含容器執行時期環境。稍微回想一下之前攻擊篇介紹的幾個手法，不外乎是拿到 --privileged 特權容器、給予過多的 CAP 能力、掛載敏感目錄等等。也因此最直觀的防禦方式就是抽掉這些能力，既粗暴又簡單。

參考 OWASP Cheat Sheet Series RULE #2 - Set a user、RULE #3 - Limit capabilities、RULE #4 - Add –no-new-privileges flag、RULE #6 - Use Linux Security Module (seccomp, AppArmor, or SELinux) 這些規則。

所以依照這些規則，先來設計一個嚴謹的容器執行環境。

docker run --rm -it --cap-drop ALL --security-opt=no-new-privileges aeifkz/my-ubuntu:v.non-root bash ;

#看一下身分是誰?
whoami ; 

#透過程式提權
/tools/suid_test ;

#從哪裡起跳，就落回哪裡
whoami ;

這段啟動程式看似平平無奇，但是背後套用了以下的防禦機制。

1. Image 內使用低權限帳號啟動程式，避免駭客取得權限後做後續進一步的滲透行為。
2. 啟動沒帶入 --privileged ，不為特權容器，因此無掛載宿主機裝置以及關閉安全機制。
3. 放棄所有 CAP 能力，但這部分需要微調測試，有需要的話再帶入 --cap-add 新增白名單
4. 啟動預設開啟 seccomp、apparmor。selinux 的部分要則請參考 Day 33 - Container SELinux 防禦機制
5. 啟動帶入 --security-opt=no-new-privileges，所以該容器無法透過 setuid 或是 setgid 進行提權。"When this flag is used, calls to setuid and setgid will have no effect. This prevents the container from acquiring new privileges."
6. 不與宿主機的作業系統共用 pid、network 資訊。

今日總結 :

• 本日回顧 :
  • 套用啟動容器安全參數算是簡單易懂的一環，也是個很好進行容器防禦的方式，但問題在於如何兼顧最小化權限跟功能就是門藝術了。另外 no-new-privileges 的部分也可以參考 hackercat 的 容器安全之 Docker 限制 SUID 權限，利用 No New Privileges 預防容器內提權。
• 次日預告 :
  • 除了啟動參數之外，明天會說明 docker 的 user remapping 功能。因為該功能必須調整 docker 的啟動設定檔，所以就不歸類在今天的類別裡面。